In many computing systems, low-level instruction code is used as an intermediary between the hardware components of the computing system and the operating software and other high-level software executing on the computing system. In some computer systems, this low-level instruction code is known as the Basic Input and Output System (“BIOS”). The BIOS provides a set of software routines that allow high-level software to interact with the hardware components of the computing system using standard calls.
Because of limitations of the BIOS in many PC-compatible computers, a new specification for creating the firmware that is responsible for booting the computer and for intermediating the communication between the operating system and the hardware has been created. The new specification is called the Extensible Firmware Interface (“EFI”) Specification and is available from INTEL CORPORATION. The original EFI Specification from INTEL CORPORATION is also being extended by the Unified Extensible Firmware Interface Forum (“UEFI”).
The EFI Specification describes an interface between the operating system and the system firmware. In particular, the Specification defines the interface that platform firmware must implement and the interface that the operating system may use in booting. How the firmware implements the interface is left up to the manufacturer of the firmware. The EFI Specification provides mechanisms for EFI drivers to communicate with each other, and the EFI core provides functions such as allocation of memory, creating events, setting the clock, and many others. This is accomplished through a formal and complete abstract specification of the software-visible interface presented to the operating system by the platform and the firmware.
INTEL CORPORATION has also provided further details regarding recommended implementation of EFI and UEFI in the form of The INTEL Platform Innovation Framework for EFI (“the Framework”). Unlike the EFI Specification, which focuses only on programmatic interfaces for the interactions between the operating system and system firmware, the Framework is a group of specifications that together describe a firmware implementation that has been designed to perform the full range of operations that are required to initialize the platform from power on through transfer of control to the operating system.
The Framework describes EFI firmware being executed in two major phases: the Pre-EFI Initialization (“PEI”) phase and the Driver Execution Environment (“DXE”) phase. PEI includes the minimum amount of program code needed to perform basic platform initialization and is executed from non-volatile memory. When PEI has completed its initialization, including the initialization of main memory, control passes to the DXE, which performs higher-level platform initialization and diagnostic functions. Pre-EFI Initialization modules (“PEIMs” or “modules”) are specialized drivers that are executed during PEI. PEIMs are generally utilized to perform the actual hardware initialization that takes place during PEI.
It is sometimes desirable to have certain types of modules execute in both the PEI and the DXE. While the Framework provides limited functionality for executing a module in both the PEI phase and the DXE phase, the mechanism provided by the Framework to launch a module in both PEI and DXE suffers from several significant drawbacks. First, utilizing the mechanism provided by the Framework, the module is loaded once in PEI and then loaded again when DXE starts. Loading the module twice in this manner requires additional processing time, especially if the module must be decompressed prior to execution, and also consumes twice the memory. Second, there is a gap between the time the module is shut down in the PEI and the time the module is re-launched in the DXE. This gap causes an undesirable discontinuity of execution of the module.
It is with respect to these considerations and others that the various embodiments of the invention have been made.